Skip to main content

API Gateway

An API gateway is single entry point behind which sits multiple services. For example, a bunch of individual functions such as postcode/zip lookup, getting information on a public company, returning vehicle information from a license plate etc.

Why use an API Gateway? This just adds another layer.​

Indeed it does. However, most services (especially publicly exposed ones) have common requirements in addition to their core function. Throttling requests, authentication/authorisation, audit, caching etc. Without an API gateway every service would need to provide their own implementation of some, or all, of these features.

Other benefits such as service interface abstraction become possible. In plain English, this means the ability to hide specific interface implementation details from a service consumer?

What is interface abstraction?​

Say you use a certain provider for your post/zip code lookup service. The provider gives you a REST API specification. You then share that specification with the entire organisation. Everyone who wants that function doesn’t need to build it, they use what you’ve provided. Brilliant. Time passes, lots of projects use the service, money is saved, all is good.

More time passes and there’s a need to switch service providers. Well, now everyone who is using that vendor specific interface now needs to change their code.

An alternative architecture could have been put in place to eliminate, or at least reduce, the impact of this scenario. A new service/s are created and exposed using the API gateway. The new service exposes a vendor neutral version of the underlying post/zip code service. Service consumers make requests to the interface in the API gateway which routes the request onto the underlying vendor specific service.

Should the post/zip code provider change in future then consumers of the service will see little to no change in the interface. Which means no code changes. This is of course the ideal situation. In the real world it’s not uncommon to find the API gateway doesn’t quite deliver on the promise. :)

Common API Gateway Providers​

There are lots. A quick Google search will reveal the current main players. I’m only going ot cover a couple here that I’ve worked with.

  • Kong - At the time of writing Kong is probably the most common I’ve seen. Open source, well supported, used by many large enterprises.
  • Amazon API Gateway - AWS vendor specific implementation. As you would expect, it integrates well with other AWS services. It does of course introduce some vendor lock-in. Chances are it’ll be there or not for your particular needs. Enterprise Architecture would (should) have identified if this is an an acceptable building block.